home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-mimemhs-mapping-01.txt < prev    next >
Encoding:
Text File  |  1993-03-03  |  22.1 KB  |  873 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  7.  
  8.  
  9.                  Mapping between X.400 and RFC-822 Message Bodies
  10.  
  11.                              Thu Jun 25 19:32:19 1992
  12.  
  13.  
  14.                              Harald Tveit Alvestrand
  15.                                    SINTEF DELAB
  16.                         Harald.Alvestrand@delab.sintef.no
  17.  
  18.  
  19.                               Steve Hardcastle-Kille
  20.                                  ISODE Consortium
  21.                                 S.Kille@isode.com
  22.  
  23.  
  24.                                  Robert S. Miles
  25.                                 Soft*Switch, Inc.
  26.                                 rsm@spyder.ssw.com
  27.  
  28.  
  29.                                  Marshall T. Rose
  30.                            Dover Beach Consulting, Inc.
  31.                               mrose@dbc.mtview.ca.us
  32.  
  33.  
  34.                                 Steven J. Thompson
  35.                                 Soft*Switch, Inc.
  36.                                sjt@gateway.ssw.com
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.           Status of this Memo
  44.  
  45.           This document is an Internet Draft.  Internet Drafts are
  46.           working documents of the Internet Engineering Task Force
  47.           (IETF), its Areas, and its Working Groups. Note that other
  48.           groups may also distribute working documents as Internet
  49.           Drafts.
  50.  
  51.           Internet Drafts are draft documents valid for a maximum of six
  52.           months. Internet Drafts may be updated, replaced, or obsoleted
  53.           by other documents at any time.  It is not appropriate to use
  54.  
  55.  
  56.  
  57.  
  58.  
  59.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 1]
  60.  
  61.  
  62.  
  63.  
  64.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  65.  
  66.  
  67.           Internet Drafts as reference material or to cite them other
  68.           than as a "working draft" or "work in progress."
  69.  
  70.           Please check the I-D abstract listing contained in each
  71.           Internet Draft directory to learn the current status of this
  72.           or any other Internet Draft.
  73.  
  74.           If consensus is reached in the IETF MIME-MHS Interworking
  75.           Working Group, it will be submitted to the IESG asking that it
  76.           be recommended to the IAB as a Proposed Standard protocol
  77.           specification.
  78.  
  79.           Please send comments to the MIME-MHS mailing list:
  80.           <mime-mhs@surfnet.nl>
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 2]
  118.  
  119.  
  120.  
  121.  
  122.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  123.  
  124.  
  125.           1.  Introduction
  126.  
  127.           The Internet community is a large collection of networks under
  128.           autonomous administration, but sharing a core set of
  129.           protocols.  These are known as the Internet suite of protocols
  130.           (or simply "TCP/IP").
  131.  
  132.           Use of electronic-mail in the Internet is defined primarily by
  133.           one document, RFC-822[1], which defines the standard format
  134.           for the exchange of messages.  RFC-822 has proven immensely
  135.           popular; in fact, the 822-connected Internet, is larger than
  136.           the scope of the IP-connected Internet.
  137.  
  138.           The framework provided by RFC-822 allows for memo-based
  139.           textual messages.  Each message consists of two parts:  the
  140.           headers and the body.  The headers are analogous to the
  141.           structured fields found in an inter-office memo, whilst the
  142.           body is free-form.  Both parts are encoded using ASCII.
  143.  
  144.           Recently, the Internet Engineering Task Force (IETF) has
  145.           developed an document called
  146.  
  147.                Multipurpose Internet Mail Extensions
  148.  
  149.           or MIME RFC-1341.  The title is actually misleading.  MIME
  150.           defines structure for Internet message bodies.  It is not an
  151.           extension to RFC-822.
  152.  
  153.           Independently of this, the International standards community
  154.           developed a different framework in 1984 (some say that's the
  155.           problem).  This framework is known as the OSI Message Handling
  156.           System (MHS) or sometimes X.400.
  157.  
  158.           Since the introduction of X.400(84), there has been work
  159.           ongoing for defining mappings between MHS and RFC-822.  The
  160.           most recent work in this area is RFC-1327[3], which focuses
  161.           primarily on translation of envelope and headers.  This
  162.           document is complimentary to RFC-1327 as it focuses on
  163.           translation of the message body.  The mappings defined are
  164.           largely symmetrical with respect to MIME and MHS structuring
  165.           semantics, although the MIME semantics are somewhat richer.
  166.           In order to provide for reversible transformations, MHS
  167.           heading extensions are used to carry the additional MIME
  168.           semantics.
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 3]
  176.  
  177.  
  178.  
  179.  
  180.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  181.  
  182.  
  183.           2.  Approach
  184.  
  185.           The mappings have been specifically designed to provide
  186.           optimal behavior for three different scenarios:
  187.  
  188.           (1)  Allow a MIME user and an MHS user to exchange an
  189.                arbitrary binary content;
  190.  
  191.           (2)  Allow MIME content-types to "tunnel" through an MHS relay
  192.                (that is, two MIME users can exchange content-types
  193.                without loss through an MHS relay); and,
  194.  
  195.           (3)  Allow MHS body parts to "tunnel" through a MIME relay
  196.                (that is, two MHS users can exchange body parts without
  197.                loss through a MIME relay).
  198.  
  199.           Other, related, scenarios can also be easily accommodated.
  200.  
  201.           To facilitate the mapping process, the Internet Assigned
  202.           Numbers Authority (IANA) maintains a table termed the "IANA
  203.           MHS/MIME Equivalence Table".  Once an enterprise has
  204.           registered an OID to describe an MHS body part, it should
  205.           complete a corresponding registry with the IANA for a MIME
  206.           content-type/subtype.  In practice, the corresponding
  207.           content-type will be "application", with an appropriate choice
  208.           of sub-type and possible parameters.  If a new MIME content-
  209.           type/subtype is registered with the IANA without a
  210.           corresponding entry in the Equivalence Table, the IANA will
  211.           assign it an OID, from the arc defined in this memo. See [4],
  212.           section 5 for details.
  213.  
  214.           The companion document, "Equivalences between 1988 X.400 and
  215.           RFC-822 Message Bodies"[4], defines the initial configuration
  216.           of this table.  The mappings described in both this document
  217.           and the companion document use the notational conventions of
  218.           RFC-1327.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  239.  
  240.  
  241.           3.  Mapping between X.400 and RFC-822 Message Bodies
  242.  
  243.           MHS messages comprise of a heading and a body.  The body is a
  244.           sequence of body parts.  A body part may be a nested message.
  245.  
  246.           A MIME message consists of headers and a content.  For the
  247.           purpose of discussion, the content may be structured
  248.           (multipart or message), or atomic (otherwise).  An element of
  249.           a structured content may be a message or a content.  Both
  250.           message and structured content have subtypes which do not have
  251.           direct analogies in MHS.
  252.  
  253.           The mapping between X.400 and RFC-822 message bodies which
  254.           this document defines is symmetrical for the following cases:
  255.  
  256.           (1)  any atomic body part
  257.  
  258.           (2)  multipart: digest and mixed subtypes
  259.  
  260.           (3)  message/rfc822
  261.  
  262.           RFC-1327 specifies the mappings for headers.  Section 5
  263.           describes how those mappings are modified by this document.
  264.           When mapping between an MHS body and a MIME content, the
  265.           following algorithm is used:
  266.  
  267.  
  268.           3.1.  Mapping from X.400 to RFC-822
  269.  
  270.           This section replaces the text in RFC-1327 starting at the
  271.           bottom of page 84,
  272.  
  273.                The IPMS.Body is mapped into the RFC-822 message body.
  274.                Each IPMS.BodyPart is converted to ASCII as follows:
  275.  
  276.           and continuing up to and including page 86 of Section 5.3.4 of
  277.           RFC-1327.
  278.  
  279.           If the IPMS.Body
  280.  
  281.                Body ::=
  282.                    SEQUENCE OF
  283.                        BodyPart
  284.  
  285.           consists of a single body part, then the RFC-822 message body
  286.  
  287.  
  288.  
  289.  
  290.  
  291.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 5]
  292.  
  293.  
  294.  
  295.  
  296.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  297.  
  298.  
  299.           is constructed as the MIME content corresponding to that body
  300.           part.
  301.  
  302.           If the body part is a forwarded IPMessage, the mapping is
  303.           applied recursively.  Otherwise, to map a specific MHS body
  304.           part to a MIME content-type, the IANA MHS/MIME Equivalence
  305.           table is consulted.  If the MHS body part is not identified in
  306.           this table, then the body-part is mapped onto an
  307.           "application/x400-bp" content, as specified in [4].
  308.  
  309.           If the IPMS.Body consists of more than one body part, then the
  310.           RFC-822 message body is constructed as a
  311.  
  312.                multipart/mixed
  313.  
  314.           content-type, unless all of the body parts are messages, in
  315.           which case it is mapped to a
  316.  
  317.                multipart/digest
  318.  
  319.           content-type.  Each component of the multipart content-type
  320.           corresponds to a IPMS.BodyPart, preserving the ordering of the
  321.           body parts in the IPMS.Body.
  322.  
  323.           There is one case which gets special treatement.  If the
  324.           IPMS.Body consists solely of a single IA5Text body part, then
  325.           the RFC822 message body is NOT marked as a MIME content.  This
  326.           prevents RFC822 mailers from invoking MIME function
  327.           unnecessarily.
  328.  
  329.  
  330.           3.2.  Mapping from RFC-822 to X.400
  331.  
  332.           First, replace the first paragraph of Section 5.1.3 on page 72
  333.           of RFC-1327 to read as:
  334.  
  335.                The IPM (IPMS Service Request) is generated according to
  336.                the rules of this section.  The IPMS.body usually
  337.                consists of one IPMS.BodyPart of type
  338.  
  339.                     IPMS.IA5TextBodyPart
  340.  
  341.                with
  342.  
  343.                     IPMS.IA5TextBodyPart.parameters.repertoire
  344.  
  345.  
  346.  
  347.  
  348.  
  349.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 6]
  350.  
  351.  
  352.  
  353.  
  354.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  355.  
  356.  
  357.                set to the default (ia5), which contains the body of the
  358.                RFC-822 message.  However, if the 822.MIME-Version header
  359.                field is present, a special algorithm is used to generate
  360.                the IPMS.body.
  361.  
  362.  
  363.           Second, replace the "Comments:" paragraph on page 74 to reads
  364.           as:
  365.  
  366.                Comments:
  367.  
  368.                     If an 822.MIME-Version header field is not present,
  369.                     generate an IPMS.Bodypart of type
  370.  
  371.                          IPMS.IA5TextBodyPart
  372.  
  373.                     with
  374.  
  375.                          IPMS.IA5TextBodyPart.parameters.repertoire
  376.  
  377.                     set to the default (ia5), containing the value of
  378.                     the fields, preceded by the string "Comments: ".
  379.                     This body part shall preceed the other one.
  380.  
  381.           Third, add the remainder of this section to the end of Section
  382.           5.1.3 of RFC-1327.
  383.  
  384.           If the 822.MIME-Version header field is present, the following
  385.           mapping rules are used to generate the IPMS.body.
  386.  
  387.           If the MIME content-type is one of:
  388.  
  389.           (1)  any atomic body part
  390.  
  391.           (2)  multipart: digest and mixed subtypes
  392.  
  393.           (3)  message/rfc822
  394.  
  395.           then the symmetric mapping applies as described in Section
  396.           4.1.
  397.  
  398.           Otherwise, three cases remain, which are discussed in turn.
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 7]
  408.  
  409.  
  410.  
  411.  
  412.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  413.  
  414.  
  415.           3.2.1.  Mappings from the Message Content Type
  416.  
  417.  
  418.           3.2.1.1.  Message/External-Body
  419.  
  420.           This is mapped into a mime-body-part, as specified in [4].
  421.  
  422.  
  423.           3.2.1.2.  Message/Partial
  424.  
  425.           This is mapped onto a message, and the following heading
  426.           extension is used.  The extension is derived from the
  427.           message/partial parameters:
  428.  
  429.                partial-message  HEADING-EXTENSION
  430.                    VALUE PartialMessage
  431.                    ::= id-hex-partial-message
  432.  
  433.                PartialMessage ::=
  434.                    SEQUENCE {
  435.                        number INTEGER,
  436.                        total  INTEGER,
  437.                        id     IA5String
  438.                    }
  439.  
  440.           If this heading is present when mapping from MHS to MIME, then
  441.           a message/partial should be generated.
  442.  
  443.  
  444.           3.2.2.  Mappings from the Multipart Content-type
  445.  
  446.           In MIME, a multipart content, refers to a set of content-
  447.           types, not a message with a set of content-types.  However,
  448.           the multipart content will always be mapped to an MHS message.
  449.           The only mandatory field in the heading is the IPM.this-IPM,
  450.           which must always be generated (by the gateway).  A
  451.           IPM.subject field should also be generated where there is no
  452.           "real" heading.  This will present useful information to the
  453.           non-MIME capable X.400(88) and to all X.400(84) UAs.
  454.  
  455.           The following heading extension should be generated, with the
  456.           enumerated value set according to the subtype:
  457.  
  458.                multipart-message HEADING-EXTENSION
  459.                    VALUE MultipartType
  460.  
  461.  
  462.  
  463.  
  464.  
  465.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 8]
  466.  
  467.  
  468.  
  469.  
  470.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  471.  
  472.  
  473.                    ::= id-hex-multipart-message
  474.  
  475.                MultipartType ::=
  476.                    ENUMERATED {
  477.                        mixed(1),
  478.                        alternative(2),
  479.                        digest(3),
  480.                        parallel(4)
  481.                    }
  482.  
  483.  
  484.           The IPM.subject fields for the various types are:
  485.  
  486.           mixed:        "Multipart Message"
  487.           alternative:  "Alternate Body Parts containing the same information"
  488.           digest:       "Message Digest"
  489.           parallel:     "Body Parts to be interpreted in parallel"
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.           Alvestrand, Kille, Miles, Rose, Thompson   Exp Dec 92 [Page 9]
  524.  
  525.  
  526.  
  527.  
  528.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  529.  
  530.  
  531.           4.  Mapping between X.400 and RFC-822 Message Headers
  532.  
  533.           Replace the first paragraph of Section 3.3.4 on page 26 of
  534.           RFC-1327 to read as:
  535.                In cases where T.61 strings are used only for conveying
  536.                human-interpreted information, the aim of this mapping is
  537.                to render the characters appropriately in the remote
  538.                character set, rather than to maximize reversibility.
  539.                For these cases, the following steps are followed to find
  540.                an appropriate encoding:
  541.  
  542.                1) If all the characters in the string are contained
  543.                within the ASCII repertoire, the string is simply copied.
  544.  
  545.                2) If all the characters in the string are from an IANA-
  546.                registered character set, then the appropriate encoded-
  547.                word(s) according to [5] are generated instead.
  548.  
  549.                3) If the characters in the string are from a character
  550.                set which is not registered with the IANA, then the
  551.                mappings to IA5 defined in CCITT Recommendation X.408
  552.                (1988) shall be used [CCITT/ISO88a].  These will then be
  553.                encoded in ASCII.
  554.  
  555.                This approach will only be used for human-readable
  556.                information (Subject and FreeForm Name).
  557.  
  558.                When mapping from an RFC-822 header, when an encoded-word
  559.                (as defined in [5]) is encountered:
  560.  
  561.                1) If all the characters contained therein are mappable
  562.                to T.61, the string content shall be converted into T.61.
  563.  
  564.                2) Otherwise, the encoded-word shall be copied directly
  565.                into the T.61 string.
  566.  
  567.           Modify procedure "2a" on page 56 of RFC-1327 to read as:
  568.                If the IPMS.ORDescriptor.free-form-name is present,
  569.                convert it to ASCII or T.61 (Section 3.3.4), and use this
  570.                as the 822.phrase component of the 822.mailbox construct.
  571.  
  572.           Modify the final paragraph of procedure "2" on page 55 of
  573.           RFC-1327 to read as:
  574.                The string is then encoded into T.61 or ASCII using a
  575.                human-oriented mapping (as described in Section 3.3.4).
  576.  
  577.  
  578.  
  579.  
  580.  
  581.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 10]
  582.  
  583.  
  584.  
  585.  
  586.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  587.  
  588.  
  589.                If the string is not null, it is assigned to
  590.                IPMS.ORDescriptor.free-form.name.
  591.  
  592.           Modify the second paragraph of procedure "3" on page 55 of
  593.           RFC-1327 to read as:
  594.                If the 822.group construct is present, any included
  595.                822.mailbox is encoded as above to generate a separate
  596.                IPMS.ORDescriptor.  The 822.group is mapped to T.61 or
  597.                ASCII (as described in Section 3.3.4), and an
  598.                IPMS.ORDescriptor with only an free-form-name component
  599.                is built from it.
  600.  
  601.           Modify procedure "822.Subject" on page 62 of RFC-1327 to read
  602.           as:
  603.                Mapped to IMPS.Heading.subject.  The field-body uses the
  604.                human-oriented mapping referenceed in Section 3.3.4.
  605.  
  606.           Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327
  607.           to read as:
  608.                Mapped to "Subject:".  The contents are converted to
  609.                ASCII or T.61 (Section 3.3.4).  Any CRLF are not mapped,
  610.                but are used as points at which the subject field must be
  611.                folded.
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 11]
  640.  
  641.  
  642.  
  643.  
  644.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  645.  
  646.  
  647.           5.  OID Assignments
  648.  
  649.           MIME-MHS DEFINITIONS ::= BEGIN
  650.  
  651.           EXPORTS -- everything --;
  652.  
  653.           IMPORTS
  654.               experimental
  655.                   FROM RFC1155-SMI;
  656.  
  657.                 -- this assignment will change if this document --
  658.                      -- is issued as a standards-track RFC --
  659.           mime-mhs OBJECT IDENTIFIER ::= { experimental 34 }
  660.  
  661.  
  662.           mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }
  663.  
  664.           id-hex-partial-message OBJECT IDENTIFIER ::=
  665.                   { mime-mhs-headings 1 }
  666.           id-hex-multipart-message OBJECT IDENTIFIER ::=
  667.                   { mime-mhs-headings 2 }
  668.  
  669.  
  670.           mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }
  671.  
  672.  
  673.           END
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 12]
  698.  
  699.  
  700.  
  701.  
  702.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  703.  
  704.  
  705.           6.  Security Considerations
  706.  
  707.  
  708.           There are no explicit security provisions in this document.
  709.           However, a warning is in order.  This document maps two
  710.           mechanisms between RFC822 and X.400 that could cause problems.
  711.           The first is the transfer of binary files.  The inherent risks
  712.           are well known and won't be reiterated here.  The second is
  713.           the propagation of strong content typing.  The typing can be
  714.           used to automatically "launch" or initiate applications
  715.           against those contents.  Any such launching leaves the invoker
  716.           vulnerable to application-specific viruses; for example, a
  717.           spreadsheet macro or Postscript command that deletes files.
  718.           See [2], Section 7.4.2 for a Postscript-specific discussion of
  719.           this issue.
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 13]
  756.  
  757.  
  758.  
  759.  
  760.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  761.  
  762.  
  763.           7.  References
  764.  
  765.           [1]  D.H. Crocker, Standard for the Format of ARPA Internet
  766.                Text Messages.  Request for Comments 822, (August, 1982).
  767.  
  768.           [2]  N. Borenstein, N. Freed, MIME: Mechanisms for Specifying
  769.                and Describing the Format of Internet Message Bodies.
  770.                Request for Comments 1341, (June, 1992).
  771.  
  772.           [3]  S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO
  773.                10021 and RFC-822.  Request for Comments 1327, (May,
  774.                1992).
  775.  
  776.           [4]  H.T. Alvestrand, S.J. Thompson, Equivalences between 1988
  777.                X.400 and RFC-822 Message Bodies.  Internet-Draft, (June,
  778.                1992).
  779.  
  780.           [5]  K. Moore.  Representation of Non-ASCII Text in Interenet
  781.                Message Headers.  Message Bodies.  Request for Comments
  782.                1342, (June, 1992).
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 14]
  814.  
  815.  
  816.  
  817.  
  818.           draft          MHS/RFC-822 Message Body Mapping         Jun 92
  819.  
  820.  
  821.           Table of Contents
  822.  
  823.  
  824.            Status of this Memo ....................................    1
  825.           1 Introduction ..........................................    3
  826.           2 Approach ..............................................    4
  827.           3 Mapping between X.400 and RFC-822 Message Bodies ......    5
  828.           3.1 Mapping from X.400 to RFC-822 .......................    5
  829.           3.2 Mapping from RFC-822 to X.400 .......................    6
  830.           3.2.1 Mappings from the Message Content Type ............    8
  831.           3.2.1.1 Message/External-Body ...........................    8
  832.           3.2.1.2 Message/Partial .................................    8
  833.           3.2.2 Mappings from the Multipart Content-type ..........    8
  834.           4 Mapping between X.400 and RFC-822 Message Headers .....   10
  835.           5 OID Assignments .......................................   12
  836.           6 Security Considerations ...............................   13
  837.           7 References ............................................   14
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.           Alvestrand, Kille, Miles, Rose, Thompson  Exp Dec 92 [Page 15]
  872.  
  873.